Developers of data-centric solutions routinely face situations in which data representations used by applications differ substantially from ones used by databases. A traditional reason for this distinction has included impedance mismatches between programming language abstractions and persistent storage; developers want to encapsulate business logic into objects, yet most enterprise data is stored in relational database systems. A further reason for the distinction is to enable data independence. Even if applications and databases start with the same data representation, they can evolve, leading to differing data representations that must be bridged or mapped. Yet a further reason is independence from Data Base Management System (DBMS) vendors: many enterprise applications run in the middle tier and need to support backend database systems of varying capabilities, which can require different data representations. Thus, in many enterprise systems separation between application models and database models has become a design choice rather than a technical impediment.
The data transformations required to bridge or map applications and databases can be extremely complex. Even relatively simple object-to-relational (O/R) mapping scenarios where a set of objects is partitioned across several relational tables can require transformations that contain outer joins, nested queries, and case statements in order to reassemble objects from tables. Implementing such transformations can be difficult, especially since the data usually needs to be updatable, a common requirement for many enterprise applications. For example, a recent study indicated that coding and configuring object-to-relational (O/R) data access accounts for up to 40% of total project effort.
Since the mid-1990's, client-side data mapping layers have become a popular alternative to hand coding data access logic, funneled by the growth of Internet applications. A core function of such a layer is to provide an updatable view that exposes a data model closely aligned with the application's data model, driven by an explicit mapping. Many commercial products and open source projects have emerged to offer these capabilities. Virtually every enterprise framework provides a client-side persistence layer (e.g., Enterprise Java Bean (EJB) in Java 2 Platform, Enterprise Edition (J2EE)). Most packaged business applications, such as, for instance, Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) applications incorporate proprietary data access interfaces (e.g., Business Application Programming Interfaces (BAPIs)).
Currently in order to program against an object-relational mapping technology, such as an entity frame work, database customers (e.g., users, database administrators, database application developers, etc.) typically utilize SQL metadata embedded within application programs. Such an approach however forces database application programmers, users, administrators, and the like, to develop applications or code fragments that are database vendor (e.g., Oracle, IBM, Sybase, Microsoft, etc.) and/or database type (e.g., SQL Server, DB2, dBase, . . . ) specific which can be extremely wasteful in terms of expenditure and time.